Oasis memo
implementations
Performant and Confidentiality-Preserving Smart Contracts + Blockchains
A humane blockchain programming framework.
Runtime environment for Oasis services and EVM smart contracts
クライアントとCompute Node間では、クライアント秘密鍵保持の公開鍵暗号
enclaveも秘密鍵をもつ？
オンチェーンでのstateはkey managerが管理する共通鍵暗号でアップロード
key managerとenclaveがユーザーごとのsecret shareを保持？
https://gyazo.com/92254f5bee7b3bdad403e979bccd15df
ユーザーは復号化stateをどう取る？
アカウント（の公開鍵）と共通鍵の紐付けに対する状態はどこでもつ？key manager? compute node?
key managerもTEE？
可用性高い鍵管理は複数のTEEに保存すればよいが、exposure riskとavailabilityのトレードオフ。
Replicated TEEs
key managerがTEE内でmaster secretを生成し他のkey manager nodeに複製
master secretからk_cidをderive
Distributed key generation
short-term keys, long-term keys
なぜcompute nodesとkey managersが分離？
workflow
クライアントはcompute nodesの優先度リストを保持
contract creation
クライアントがcontract codeをCompに送りTEEにload
TEEが新しいcid (contract id)を生成
cidに基づいた公開鍵と共通鍵(k_cid)をそれぞれkey managerから取得
key managerはどうやってcidを知る？
暗号化初期状態Enc(k_cid, 0)とattestation $ \sigma_{TEE}（初期化の正当性、pk_cidが正しいcidのpubkeyか）を生成し、IASとcommunicationしその証明をgetし、certified attestaion $ \piを得る。
https://gyazo.com/ddc6ebceb8af1fa6ff88d6b1cc8df903
をvalidator nodeに送信し検証。
https://gyazo.com/fbfd897af476d0471b53c061ed73dfb6
Request execution
クライアントがpk_cidをblockchainから取得し、(cid, inp_ct = Enc(pk_cid, inp))をCompに送信
公開鍵はコントラクトのみに紐づき、ユーザー間で同じ
Compがブロックチェーンからcontract nodeと暗号化preciout stateを取得し、TEEにload。
Atomic delivery
TEEからのクライアントとブロックチェーンへの処理はアトミックでなければならない。
TEEがkey managerからfresh kを取得し、PにEnc(k, m_1)を送り、TEEがblockchainにm_2を送る。
$ \pi_{m_2}の検証が確認できたらTEEはPにk送り、Pはm_1を得ることが可能に。
implementation note
Runtime attestation key handling.
verify_rak_binding
Key Derivation Function
Methods exported to remote clients via EnclaveRPC.
policy
seal
code: g2
fn new_d2() -> DeoxysII {
let mut seal_key = egetkey(Keypolicy::MRENCLAVE, &POLICY_SEAL_CONTEXT);
let d2 = DeoxysII::new(&seal_key);
seal_key.zeroize();
d2
}